Skip to content

filesys: a handle on an existing file is writable#259

Merged
LinuxJedi merged 3 commits into
LinuxJedi:mainfrom
codewiz:fix/filesys-writable-handles
Jul 23, 2026
Merged

filesys: a handle on an existing file is writable#259
LinuxJedi merged 3 commits into
LinuxJedi:mainfrom
codewiz:fix/filesys-writable-handles

Conversation

@codewiz

@codewiz codewiz commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Workbench could not snapshot icons on a HOSTFS volume: the Snapshot ended
in a seek error.

The packet trace shows icon.library's path -- lock the .info, OpenFromLock
it, read the header, write it back through the same handle:

locate "Boing.info" (lock 0x3AA0A8)
packet type 8    -> res1=0x3AA1E0 res2=0      ACTION_LOCATE_OBJECT
packet type 1026 -> res1=0xFFFFFFFF res2=0    ACTION_FH_FROM_LOCK, ok
packet type 82   -> res1=0x3A res2=0          ACTION_READ, 58 bytes
packet type 87   -> res1=0xFFFFFFFF res2=219  ACTION_WRITE, seek error
packet type 1007 -> res1=0xFFFFFFFF res2=0    ACTION_END

ACTION_FH_FROM_LOCK opened the host file with File::open, i.e.
read-only, so write_all failed with a host error that host_error falls
through to ERROR_SEEK_ERROR. ACTION_FINDINPUT had the same bug:
Open(MODE_OLDFILE) yields a read/write handle on the Amiga, and
OpenFromLock's handle is writable regardless of the lock's access mode.

Both now go through open_existing(), which opens read/write and falls
back to read-only if the host refuses -- a later write then fails, which
is what a protected file does on the Amiga too.

Covered by a new test driving both open paths through a real write and
checking the bytes on disk.

🤖 Generated with Claude Code

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes HOSTFS semantics for opening existing files so that handles returned via OpenFromLock() and Open(MODE_OLDFILE) are writable (matching AmigaDOS behavior). This unblocks Workbench icon snapshotting on HOSTFS volumes, which previously failed due to a host-side read-only handle.

Changes:

  • Route ACTION_FH_FROM_LOCK and ACTION_FINDINPUT through a new open_existing() helper to prefer read/write opens (with a read-only fallback).
  • Add a focused regression test that exercises both open paths and verifies a real write succeeds and persists on disk.
  • Refactor/DRY some filesystem packet-driving test setup via a new FsTester helper.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/filesys.rs
codewiz and others added 2 commits July 23, 2026 15:53
Open(MODE_OLDFILE) and OpenFromLock() both opened the host file
read-only, so any write through the handle failed with a host error that
maps to ERROR_SEEK_ERROR. On AmigaOS both hand out a read/write handle,
which Workbench's Snapshot relies on: icon.library locks the .info,
OpenFromLock()s it, reads the header and writes it back through the same
handle.

Open read/write, falling back to read-only if the host refuses; the
write then fails, as it does for a protected file on the Amiga.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Shorten open_existing's comment to the behaviour rather than the one bug
that motivated it. Factor the packet-driving boilerplate the
writable-handles and seek tests duplicated into an FsTester harness
(mount, startup packet, send, name/buffer helpers, temp-dir cleanup on
drop), and drop the redundant _like_iffparse suffix from the seek test's
name.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@codewiz
codewiz force-pushed the fix/filesys-writable-handles branch from 093fb03 to 351bc95 Compare July 23, 2026 06:53
open_existing fell back to a read-only handle on any error from the
read/write open, which could mask an unrelated failure as success and
discarded the original error. Fall back only for PermissionDenied and
ReadOnlyFilesystem -- a read-only file or host mount, the cases we mean
to open read-only -- and propagate anything else unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@LinuxJedi
LinuxJedi merged commit 9893f6c into LinuxJedi:main Jul 23, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants